Systems and methods for clickstream analysis to modify an off-line business process involving automobile sales

ABSTRACT

Methods and systems are provided herein for the analysis of clickstream data of online users. The analysis methods and systems allow for the creation of new offline business methods based on online consumer behavior. In embodiments, the output file enables the third party to select an offering for automobile sales by sales region or geography.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is based on, claims priority to, and incorporates byreference the following U.S. Provisional Patent Applications: anapplication filed Mar. 7, 2002 entitled Business Method for URLAnalysis, naming Man Jit Singh as inventor, and an application filedMar. 7, 2002 entitled Technology Platform for URL Analysis.

BACKGROUND

The advent of the Internet and the Worldwide Web has produced a host ofelectronic commerce applications, in which users interact with contentand engage in a wide variety of transactions, ranging from orderingbooks, CDs and other items, to participating in auctions, to downloadingmusic, to a host of other activities. Methods and systems are widelyused for tracking the behavior of online users, both individually and asgroups. The output from those methods and systems are typically used toadjust the structure and content of online offerings to help attractmore users, or to get current users to engage in more interaction andmore transactions with the provider.

Methods and systems for analyzing online user behavior range fromstatistical techniques, such as collaborative filtering, to use ofneural nets and similar facilities. While such methods have had somesuccess, the promise of electronic commerce remains somewhatunfulfilled. Many online businesses have failed, and those remainingfind the environment increasingly competitive. Meanwhile, manybusinesses find that online offerings (including their own), merely takebusiness away from offline product offerings, or that the onlineofferings harm offline offerings in other ways, such as by forcing pricereductions. Thus, methods and systems are needed for providing improvedcoordination between online and offline offerings. In addition, methodsand systems are needed for allowing offline businesses to take advantageof information that can be discerned from online customer behavior.

SUMMARY

Methods and systems are provided herein for the analysis of behavior ofonline users. The analysis methods and systems allow for the creation ofnew offline business methods based on online consumer behavior.

Methods and systems are also provided for providing a host computer forhandling a plurality of processes, the host system having a collectionfacility, a network, a pre-calculation facility, a calculation facility,and a post-calculation facility; obtaining an input data set of onlineuser data from a plurality of data providers, wherein the input data setrepresents HTTP transactions of a plurality of online users; and sendingan output data set to a co-location facility to permit remote access bya party other than the host.

The calculation facility may comprise providing a cluster of machinesdistributed in a parallel processing configuration. Output data may bestored in a data warehouse or sent to a collocation facility.

Methods and systems are also provided for obtaining an input data setfrom a plurality of data providers, the data set comprising datarepresenting HTTP transactions for a plurality of users; performing apre-calculation process to produce a file in a file format suitable forperforming calculations; performing calculations on the formatted file;and performing post-calculation on the results of the calculations toproduce an output file.

Methods and systems are further provided for transferring the outputfile to at least one of a co-location facility and a data warehouse.

Methods and systems are also provided for collecting the data set foranalysis by a host computer; delivering the data set to an internalnetwork; and performing an integrity check on the data.

Methods and systems are also provided wherein the formatted filecomprises data selected from the group consisting of a file identifier,a user identifier for a user who completed an HTTP transaction, a dataprovider identifier for the data provider who provided the datarepresenting the HTTP transaction, a timestamp for the HTTP transaction,a URL for the HTTP transaction, and a protocol identifier for theprotocol of the transaction.

The pre-calculation step may include reading a list of URL rules; foreach character of the URL of a formatted file, walking the character ofthe URL through the URL rules; for each rule in the URL rules, applyingthe rule to the URL of the formatted file; and outputting a modifiedURL, the modified URL reflecting the application of the rules to theoriginal URL. The modified URL may be appended to a modified formattedfile.

The methods and systems may further comprise providing a panel selectionprocess for selecting a panel of users, data for which will be used inan input data set. The process may include conducting a survey of userdemographics for an initial user panel; determining a statistic relatedto the demographics of the users in the user panel; comparing thestatistics to the statistics for a past user panel; selecting a newpanel of users representing a desired set of demographiccharacteristics; and determining whether to keep or discard a data itembased on membership of a user in the panel.

The URL of the output file may include a session identifier, a domainidentifier, a subdomain identifier, a path and a query string.

The output file may further include a hash, such as hash of the domainidentifier, the subdomain identifier, or the path.

The methods and systems described herein may include calculating ametric based on the data in the output file. The metric may be avertical market metric calculation, a search term metric calculation, orother metric.

The metric calculation may be a vertical market metric calculation thatcan include using a page extractor module for extracting dataidentifying a page of online content; using a fetcher module to retrievethe page content from a computer network; and using a classifier moduleto classify the page in at least one content category selected from agroup of possible content categories.

Metrics may be calculated using a cluster of machines configured in aparallel-processing configuration or batch-processing configuration.

In embodiments, an input URL is decomposed based on semantic meaning ofthe pages viewed by the user who executes the HTTP transaction. Thedecomposition process may be made in the presence of redirection from aprimary URL to a secondary URL or in the presence of a proxy URL for asecond URL.

Methods and systems may also include obtaining an input data setreflecting clickstream activity of a plurality of online users;analyzing user behavior reflected by the clickstream activity; drawingan inference based on the user behavior; and modifying an offlineprocess based on the inference.

The inference may relate to cross-shopping behavior between differentgoods and the offline process may be a marketing promotion. The inputdata may relate to price sensitivity of a shopper and the offlineprocess may be a pricing process for an offline item. The input data mayrelate to ordering of a user's views of items and the offline processmay relate to merchandizing and to product placement to promote viewinggoods in a particular order. The input date may relate to user buyinginterest or share of interest and the offline process may relate toforecasting offline demand for a product. The input data may relate toactions of users with respect to online content choices and the offlineprocess may relate to presenting offline media content.

In embodiments the methods and systems may include obtaining a set ofdata reflecting online actions of a plurality of users; analyzing thedata to identify characteristics of the user's behavior; and modifyingan off-line business process based on the identified characteristics.

BRIEF DESCRIPTION OF THE FIGURES

FIG. 1 is a schematic diagram showing high-level entities that interactin the methods and systems disclosed herein.

FIG. 2 is a schematic diagram showing further details of a host systemof the methods and systems disclosed herein.

FIG. 3 is a flow diagram showing high-level process steps for anembodiment of the methods and systems disclosed herein.

FIG. 4 is a flow diagram depicting steps of a pre-calculation process.

FIG. 5 is a flow diagram depicting certain high level steps of apre-calculation process of the present invention.

FIG. 6 is a flow diagram for a file conversion process.

FIG. 7 is a schematic of an embodiment of a CLF file format.

FIG. 8 is a flow diagram depicting steps for processing a URL in anembodiment of the invention.

FIG. 9 is a flow diagram showing a panel selection pre-process and apanel selection process.

FIG. 10 is a flow diagram depicting steps for a transformation processof an embodiment of the present invention.

FIG. 11 depicts a breakdown of components of a typical URL.

FIG. 12 depicts a file format for a file after adding information from asession identification process and a URL decomposition process.

FIG. 13 depicts a CL5 file format that includes information of a commonlog format as well as hashes of certain data items.

FIG. 14 is a flow diagram depicting steps for processing data for aparticular metric in an embodiment of the invention.

FIG. 15 is a diagram of a file format for output of a calculationprocess for a metric.

FIG. 16 is a schematic diagram depicting an array of machines forprocessing a metric in an embodiment of the invention.

FIG. 17 is a flow diagram depicting steps for a calculation process.

FIG. 18 is a flow diagram depicting steps for calculating a verticalsmetric in an embodiment of the invention.

FIG. 19 is a schematic diagram showing a verticals calculator and thecomponents for processing the verticals calculation.

FIG. 20 is a flow diagram for a high-level business modification processof an embodiment of the invention.

DETAILED DESCRIPTION

Referring to FIG. 1, a schematic diagram 100 shows high-level entitiesthat participate in various embodiments of methods and systems disclosedherein. The methods and systems are facilitated by a host 112, which mayhave a host computer system for facilitating various processes andfunctions described below. The host may have a plurality of clients 114who interact with the host to obtain information, analysis, or a varietyof services. In some cases the clients 114 obtain information from thehost 112 through a separate facility, such as a co-location facility118. The host 112 operates on data that it receives through a pluralityof data providers 108. The data from the data providers 110 is typicallysent to the host over a computer network 110, such as the Internet, orthrough any other conventional communications facility. The host 112 maystore data in a data facility 120, such as a data warehouse. The dataproviders 108 may each have one or more data centers, which may consistof conventional facilities for storing data relating to use of onlineservices. The data providers 108 may thus run a plurality of servers,which may be configured as server farms. The data providers 108 may beInternet Service providers, ecommerce companies, content providers,media companies, or other companies that collect data regarding userinteractions online. The data providers typically obtain their data fromthe interaction of various users 102 who trigger HTTP transactions asthey engage in online behavior with various online sites 150. The users102 interact with their computers, webTVs, PDAs or othercommunications-enabled devices, through a communication facility 104,which may represent the Internet, Worldwide Web, or other wired orwireless computer network. Those interactions are tracked and stored bythe data provider 108, and some of them are passed along to the host 112for analysis on behalf of various clients 114.

Referring still to FIG. 1, the online behavior of a user 102 istypically reflected in a series of HTTP (HyperText Transfer Protocol)transactions, HTTPS transactions. These transactions can represent HTMLpages or any of a wide variety of other content. The transactions aretypically made from a user's browser (such as an Internet Explorer orNetscape Navigator browser), but HTTP transactions can be made fromother applications as well. The browser or other application can resideon any computer, such as a laptop, personal computer, server, personaldigital assistant, WebTV, or other device.

The user 102 connects to online content sources by a computer network104, such as the Internet. The online content sources typically compriseone or more servers, which may be HTTP servers. In HTTP transactions,the servers serve content over the network in response to messages fromthe user's computer.

In their online behavior, users can interact with sites of one or morevendors through the data provider 108. Those data providers 108typically track users' interactions with their sites through logs orsimilar facilities. The logs record user behavior, tracking what pagesof content they have viewed in what sequence and for what amounts oftime. Thus, either at the desktop or at the server farm, information isbeing tracked about every HTTP transaction that the individual executesat any time. When information is tracked at a server farm it is usuallysubject to an agreement between the user and a host (such as an ISP orother site host). The agreement typically sets out the conditions underwhich the host can share data with third parties, including demographicdata about the user and data about the user's actions. A facility isthen put in place at the data provider 108 to follow rules that allowcapturing of users' transactions and sending some individuals data whilenot doing so for others.

Data about user actions can be logged in real time or collected and sentin batches by the various data providers 108. The individuals 102visiting the various online sites 150 in turn serve as data sources todata providers 108 and/or for a host 112 of the methods and systemsdescribed herein.

Data is conveyed from the data providers 108 to the host 112periodically. In some cases it is pushed from the data provider 108 tothe host 112, while in others it is pulled by the host 112 from the dataprovider 108. The transfer is typically over a network 110, such as theInternet. The information that gets pulled or pushed across is typicallyHTTP/HTTPS information for each of the users 102 of that data provider108, along with demographic information for each of those users 102.

Referring to FIG. 2, a schematic diagram shows certain components of ahost system 200. Through a series of processes and modules, the hostsystem 200 takes data from data providers 108 and converts it intoinformation suitable for a client 114. Inside the host system 200 acollection facility 202 collects the data from the various dataproviders 108. The collection facility 202 can comprise a set ofmachines that look at rules that are generated by the host 112 for thedata provider 108 in question. Thus, the host system 200 expects data ofa given format from a given data provider 108. The host system 200 canhave a timing facility that generates alerts if the data from a givendata provider 108 doesn't arrive on time.

Once the data has come across the network from the data provider 108,the host system 200 looks at individual files. Each data provider 108follows a convention for the files they send over, which may containdemographic information, clickstream data, and a file signature for allfiles the data providers send over. To ensure that all of the data wasproperly transmitted, it is desirable to use a facility such as an MD5hash of the file. If the size of the file does not match, then the host112 can determine that the file was not properly transferred.

In embodiments, the host system 200 can comprise a plurality of Free BSDX86 Intel machines, running software written in an object-orientedlanguage such as C++. Referring still to FIG. 2, the host system 200 mayalso include an internal network 204 that can handle files that comefrom the collection facility 202. The host system 200 may also include apre-calculation facility, which may consist of software modules forhandling certain operations that are necessary to generate a suitableform of file for handling by the host system 200. The host system 200may also include a calculation facility 210, which may consist ofsoftware modules and a cluster 214 of machines for running a largenumber of parallel calculations on the files that are obtained from thepre-calculation facility 208. The calculations generate variousinformation, such as metrics that relate to various characteristics ofthe behavior of users 102. The host system 200 may further include apost-calculation facility 212, which performs certain post-calculationoperations on the information generated in the calculation process. Datafiles can be sent directly to the client 114, hosted as an ASP model,sent to a co-location facility 118, or to a data warehouse 120. Furtherdetails of the various modules, machines and facilities of the hostsystem 200 are disclosed below.

Referring to FIG. 3, a flow diagram 300 depicts high-level steps for aflow of information from a user 102 through the host 112 to a client114. First, at a step 302, the user engages in an HTTP transaction orother online interaction, such as by using a browser to interact with ane-commerce website. Next, at a step 304, a data provider 108 tracks andstores information about the actions of the user 108, such as in a logfile or any of a wide range of similar facilities. The information isstored in a data center or similar facility of the data provider 108.Next, at a step 308, the host 112 collects data from the data provider108, either by having the information pushed from the data provider 108,or by pulling the information from the data provider 108. Once the datais collected, at a step 310 the host system 200 delivers it to aninternal network. Then at a step 312 the host system 200 checks the datafor integrity and alerts the data provider 108 if there is a problem.

Once the integrity of the data is confirmed at the step 312, at a step314 the pre-calculation facility of the host system 200 performs variousoperations needed to get data from multiple data providers into a commonfile format, which can be called CLF. Pre-calculation involves varioussub-processes disclosed in connection with FIG. 5 and other figuresbelow. At a step 318 the system takes the results of the pre-calculationprocess, a file in a standard format, and moves the files to thecalculation facility 210. At a step 320 the calculation facilitycalculates various metrics on the files, as desired by the operator,such as for the benefit of a given client 114 or all clients 114.

After the calculation processes of the step 320 are complete, the systemexecutes various post-calculation processes 322, typically involvingmerging, sorting and deduplicating results that were obtained bymultiple machines into a coherent set of files. Then the system 200transfers the files at a step 324, such as to a data facility 120, tothe client 114, or to a co-location facility. Further details of theseprocesses are disclosed below.

Referring to FIG. 4, a flow diagram 400 sets out a series of steps foran embodiment of a collection process. First, at a step 402, the systemreads a list of data providers. Next, at a step 404 the system assessesfor a particular data provider whether the data provider pushesinformation. If so, then at a step 408 the system waits for the filesfrom the data provider. Then at a step 410 a timing facility of thesystem determines whether the files have arrived on time. If not, thesystem determines at a step 412 whether the window of time has expiredfor the arrival of files from that data provider. If so, then at a step414 the system sends an alert to an operator of the host system or otherindividual. If at the step 412 the window has not expired, thenprocessing returns to the step 408 to wait for the files. If at the step410 the files are on time, then the processing is handed to step 424 theconfirm completion of the transfer.

If at the step 404 it is determined that the data provider does not pushinformation, then at a step 420 the system initiates a pull transactionwith the data provider. The system then determines at a step 422 whetherthe files are ready at the data provider. If at the step 422 the filesare ready at the data provider, then the system begins the transfer at astep 418. Processing is then sent to a step 424 until transfer iscomplete. Once transfer is complete (whether the data provider pushesinformation or the information was pulled by the host), then, at a step428 the system checks the file signature to confirm that the files werenot corrupted during transfer. If the file signature is determined at astep 430 to be okay, then at a step 432 the raw file data is archived.If the file signature is not okay at the step 430, then at the step 414the operations team and the data provider are alerted that the fileneeds to be transferred again. Once the data is archived at the step432, it is determined at a step 434 whether the archiving is complete.If archiving is complete at the step 434, then at a step 438 the filesare moved for further processing, such as to an internal network of thehost. If there is a problem with the archiving process, then an alert issent to the operations team at a step 440.

If at the step 422 the files are not ready at the data provider, then ata step 442 the host system waits for a period of time and checks again.A timing facility then determines at a step 444 whether time hasexpired. If not, then the system continues to wait at the step 442. Ifso, then at a step 448 an alert is sent to the data provider and theoperations team that the desired files were not ready for transfer.

In normal operation the files will transfer properly (in either a pushor pull transaction), and the system will arrive at the step 438 withfiles ready for processing on the internal systems of the host.

Once files are ready for processing, the host system can initiate apre-calculation process. High level steps of a pre-calculation processare depicted in a flow diagram 500 of FIG. 5. The pre-calculationprocess has four main high level steps. The first is a conversionprocess 502, which converts the files of a plurality of data providersinto a common file format. Off-page connector A connects the flowdiagram 500 to a flow diagram 600 of FIG. 6 that includes furtherdetails of the conversion process 502. Once the files are in a commonformat, the files are cleansed in a cleanse process 504. The details ofan embodiment of the cleanse process are set forth in a flow diagram 800of FIG. 8, which is connected to the flow diagram 500 by off-pageconnector B. Once files are cleansed, the system initiates a panelselection process 508. Details of an embodiment of a panel selectionprocess are set forth in a flow diagram 900 of FIG. 9, which isconnected to the flow diagram 500 by off-page connector C. Once thepanel selection process is complete, the system initiates atransformation process. Details of an embodiment of a transformationprocess are set forth in a flow diagram 1000 of FIG. 10, which isconnected to the flow diagram 500 by off-page connector D.

Referring to FIG. 6, the files that come from multiple data providers(DPa, DPb, DPc, DPd) are input into a conversion process shown in a flowdiagram 600. This is the only part of the pre-calculation process thatis data-provider dependent. The conversion process of the flow diagram600 takes information from multiple providers in different formats andis converted to a common file format for the host system. First, at astep 602, the host system takes in the data from different dataproviders. Next, at a step 604 the convert application (which may beembodied as an API or similar facility) loads a class that has rulesspecific to the data provider who provided the file in question. Next,at a step 608, the application uses the rules to read in the informationfrom that format for each data provider. Finally, at a step 610, thesystem outputs the data into a standard file format for the host system.In embodiments this can be called the CLF file format.

FIG. 7 shows a file format 700, CLF Format, which is the standard fileformat for a file in an embodiment of the invention. The format 700includes various data items, which include a file identifier 714, theidentity of the user whose transactions are stored in the file, or userid 702, the identity of the data provider 704, a time stamp 708, the URL(uniform resource locator) at which the user was at the time 710, andthe protocol 712 used in the transaction (e.g., HTTP, FTP, HTTPS). Inembodiments the combination of the user ID 702 and the data provider ID704 can serve as the unique file identifier 714 for the file. The fileformat can result in hundreds of lines for a given user's onlinesession, with each line representing a time and URL that the user passedduring the session.

Referring to FIG. 8, a flow diagram sets out steps for completion of afile cleansing, or cleanse, process 800. The cleanse process 800operates on files that are in the CLF format that is generated by theconversion process 700 of FIG. 7. First, at a step 802, the system readsin a list of URL rules. Next, at a step 804, the system walks each URLcharacter through the URL rules to determine how many rules apply tothat URL. In embodiments this may occur character by character for theURL in the CLF format, using a facility such as a finite state machine.For example, if the URL were www.amazon.com, the system would look atthe first character and determine how many rules apply to the character“w” located in the first position of a URL. Then the system woulddetermine how many rules apply to the second “w” in the second position,and so on, until all characters have been examined and a complete listof applicable rules has been loaded.

Once the system has determined how many rules apply at the step 804,then, at a step 808, the system applies each applicable rules againstthe URL. The rules can include filters for various data providers. Inembodiments the rules may relate to URLs alone, or may relate toURL/data provider combinations. In embodiments, the rules might relateto the user as well. An example of a rule is as follows. If the dataprovider is, for example, Amazon.com, it is known that the companymodifies its URLs (in a system that is not consistent with some URLprotocols) and include session identifiers in the URLs, but not in thequery string where they would normally appear for some data providers.By including session identifiers in the URLs, but not in the querystring, it appears that each Amazon.com URL is from a unique provider,when in fact all of them are from Amazon.com. To avoid seeing eachAmazon URL as coming from a unique provider, the system can apply a rulethat pulls out the session identifier from the URL and produces anoutput URL that doesn't have the session identifier.

Thus, at a step 810, the system outputs a cleansed URL in accordancewith the various rules.

Referring to FIG. 9, a flow diagram 900 depicts a panel selectionpreprocess 902 and a panel selection process 904. In the panel selectionpre-process, first, at a step 908 there is periodically (e.g., once perweek or once per month) a survey conducted, such as a random digit dial(RDD) survey to determine the nature of certain characteristics of theInternet community. For example, the RDD survey determines the totalnumber of Internet users in the United States, and it breaks down thoseusers into categories based on age, income, gender and location (basedon zip code or phone prefix). Next, in a statistical process 910,statisticians compile information from the RDD survey about age, income,activity level, where the user is online (home or work) and the like.Next, at a step 912 an operator of the host looks at the panel for theprevious period and at a step 914 examines historical information aboutthat panel of users. Next, upon completion of a statistical analysis ofthe previous panel and the current statistics from the RDD survey, thehost selects a panel of users at a step 918. Selection is performedbased on finding users with targeted combinations of various demographicinformation. The panel can consist of users with many different targetcombinations. In an embodiment, about one hundred combinations can beused with different demographic combinations. For example, onecombination might be males aged 16 who are earning more than $30,000.Based on historical demographic data supplied to the host by the dataproviders, it is possible to generate a representative mix of users withthe indicated characteristics for a wide variety of demographiccombinations. At a step 922 the operator of the host can compile a listof panel members, completing the preprocess 902.

Selection of panel members is a statistical process that involves somedegree of prediction. For example, selecting a panel involves guessingthat a given user will be online again for the next month, so that datacan be collected. If the host analyzes data less frequently (e.g., onlyafter the end of a given month), then the host can analyze based onactual information about what users were actually on line in that month.However, if the host wishes to deliver information more rapidly (such asweekly or daily) then it can be preferable to predict what users will beonline, rather than waiting to see what users were actually onlinebefore making a panel selection.

Next, at a step 924 the system reads the list of panel members generatedat the step 922. For a given data file in the CLF format, at a step 928the panel selection process reads the file line by line and determineswhether the user identified by the user id 702 is a panel member. Ifnot, then at a step 930 the system discards the file. If at the step 928the user id 702 is for a panel member, then at a step 932 the systemoutputs the file and sends it at a step 934 to the transformationprocess depicted further in the flow diagram 1000 of FIG. 10.

Referring to FIG. 10, steps for a transformation process are provided ina flow diagram 1000. The transformation process 1000 reads a CLF formatfile line by line taking the output from the panel selection process 900of FIG. 9. Thus, it takes output only for those files that are for panelmembers.

First, at a step 1002, the system sessionizes the data for a given user.Because a user may be logged on to a site all day (or longer), it can bedifficult to identify clearly delineated online sessions for the user.In order to sessionize the data, the system looks at data for aparticular user for a given day and walks down all of the URLs the userclicked on, looking for inactivity greater than a given time (e.g., 30minutes) in the timestamps. If there is inactivity greater than thepredetermined time, the end of a session is marked. Sessionidentification can be accomplished with conventional log file analysistools.

Once a session is identified at the step 1002, the system outputs a filein CLF format with a session id added. Thus, the file now has the userID 702, data provider ID 704, time stamp 708, URL/URLs 710 and protocol712, as well as the new element, the session ID 1010.

Once the data is divided into session at the step 1002, the systemdecomposes the URLs in the CLF format file in a step 1004. Decompositionof a URL is accomplished by applying a complex set of rules that arebased on the location of given characters at given positions in the URL.Referring to FIG. 11, a URL 1100 is divided into a plurality of sectionsdenoted in FIG. 11 by the dividers 1102. The URL of FIG. 11 iswww.yahoo.com/search?p=football&5644. As the Internet grows, and asstandard bodies introduce new top level domains, it is increasinglydifficult to decompose URLs into readily identifiable components. In theURL 1100, certain conventional components can be identified. First,there is a subdomain 1104, which in this case consists of a part of adomain, such as the characters “www” indicating the presence of aparticular domain as being on the Worldwide Web. Next, a URL may have adomain 1108, which typically consists of a prefix 1118 (often, but notalways, the name or a contraction of the name of the entity hosting theURL) and a domain type 1120 (e.g., .com for commercial entities, .netfor network companies, .gov for government entities, .org for non-profitentities, a domain type reflecting a country code, or various others).The URL may also include a path 1110, which typically reflectsnavigation within a structure of the entity that has the domain. The URLmay have a query string 1112, which may include a structure foridentifying data or content types along the indicated path. For example,the query string may include a parameter (p=) consisting of a value“football” and another parameter consisting of value S644.

The URL 1100 is just one of many configurations of URL, and thecomponents 1102 should be understood to be representative of one way ofdecomposing a URL and labeling constituent elements. Many other ways canbe used. In some decompositions, for example, the path 1110, or acombination of the path 1110 and the query string 1112, might just beidentified as a query string. In any such embodiment, the decompositionprocess 1004 breaks down the URL into constituent parts, based on rulesthat may be adjusted to reflect the URL types of a given data provideror other entity that generates URLs. The decomposition process 1004 canbe accomplished in embodiments by a rule engine that steps through thecharacters of the URL and identifies rules that apply to the givencharacter in the given location, as well as rules that apply to givenstrings of characters in given components 1102 of the URL. The ruleengine essentially figures out the grammar of the URL based on acodification of the rules for all URLs in a wide range of domains.

Maintaining a rule engine that properly decomposes URLs is difficultbecause of the emergence of facilities such as redirection services thattake a given input and redirect the user to a different URL. Thus, therules must recognize those redirections and classify the redirecting URLas the equivalent of the target URL to which the user is redirected. Inaddition, many sites (Yahoo.com, for example) are now serving as proxiesfor other sites, thereby “swallowing” content of the other sites. Thus,if a URL such as the following is visited by a user:http://yahoo.com/proxy/http://ebay.com, the system might initially betricked into concluding that the domain is yahoo.com. However, the realcontent for such a URL is actually at another domain, ebay.com. Thus,the URL analysis rules must account for the use of proxies so that theycan identify particular page content as being equivalent to other pagecontent, regardless of the use of a proxy in one case and the absence ofa proxy in the other. In some situations it may be desirable to identifyand store the fact that a page was found through a proxy as well as whatthe page was. Thus, decomposition could identify and output a file thatidentifies use of proxies.

The process of decomposing URLs also consists of examining page levelcontent for each of the paths and query strings and identifying rulesfor what paths and query strings mean in a wide range of contexts.

Referring to FIG. 12, the output of the decomposition step 1004 in oneembodiment is a file format 1200, including the basic CLF format withthe user ID 702, data provider ID 704, time stamp 708, URL/URLs 710,protocol 712, as well as the session ID 1010, and now new elements fromthe decomposition step 1004, including, for example, the domain1202,subdomain 1204, path 1208 and query string 1210.

Once a URL is decomposed at the step 1004 of FIG. 10, and the system hasgenerated the output file in the format of FIG. 12, the system proceedsto a step 1008, at which it hashes the URLs that were decomposed at thestep 1004. In an embodiment, the system takes the URLs and turns theminto MD5 hashes, producing a unique hash identifier based on thecharacter set. For each of these parts, the system generates a file thatcan perform as an index of URLs for later calculations.

The output of the hash step 1008 is a file in a format 1300 that can becalled CL5, which is depicted in FIG. 13. The CL5 format consists of theelements of the decomposition step, namely, the user ID 702, dataprovider ID 704, time stamp 708, URL/URLs 710, protocol 712, as well asthe session ID 1010, and now new elements from the decomposition step1004, including, for example, the domain1202, subdomain 1204, path 1208and query string 1210, as well as new elements, including a domain IDhash 1302, a subdomain ID hash 1304 and a path ID hash 1308. Thus, thefile format 1300 consists of the CLF format plus MD5 hashes (e.g.,sixteen character hashes) for the last three items in the CLF format.This format is useful for future processing because, among other things,it is easier to index on a fixed number of characters.

Once the hash step 1008 is complete, the transformation process 510 ofFIG. 5 is also complete. The net result is that the system hasidentified page level data and has decomposed it and indexed it based onwhat it means based on the content at the given URLs. Thus, the systemhas generated the capability of analyzing URLs based on semanticmeaning.

In embodiments, the pre-calculation processes of FIG. 5, i.e., thecleanse process 504, the panel selection process 508 and thetransformation process 510 operate line by line on incoming data. Thatis, each line goes to the cleanse process 504, then to the panelselection process 508, then to the transformation process 504, and soon.

Once a data file arrives in the system, the system checks file integrityat the step 430 of FIG. 4. Then it sends the files for thepre-calculation process of FIG. 5, applying rules across URLs and users,to produce files in a file format that can be called CLF, or compete logformat in the form identified in FIG. 7, as well as files in the formatof FIG. 12. At the end, the hash step 1008 of the transformation process504 produces a file in a format that can be called CL5, or a “gold” logformat, where some of the data is parsed out with one-way hashes to makelookups on those files easier. Taking URLs, breaking up into parts, andhashing parts of them allows the operator to create a pseudoindex tomake it easy to look them up during the calculation process describedbelow.

Once the pre-calculation process is complete the system can initiate acalculation process. The calculation process is designed to calculatevarious metrics that the operator of the host system wishes to generateout of the data provided by the data providers. Thus, the calculationprocess consists of many calculators, one or more for each metric thatthe operator wishes to calculate. The calculators can operate inparallel fashion running on clusters of machines to facilitate rapidcalculation of the various metrics. Thus, in the calculation process thesystem ends up with multiple intermediate files running across multipleservers.

Once the calculation processes are complete, another process can bekicked off. That post-calculation process picks up the multiple filesacross multiple servers to merge, sort, and deduplicate files.Essentially, the post-calculation process merges data from the variousservers that performed the calculation processes.

After post-calculation processes are complete, the resulting files canbe sent out to various locations, such as a co-location server, wherethe files may be accessed by clients of the host system, and/or to aninternal data warehouse, to allow analysts of the host to look at them.Depending on how the host decides to partition a day's data there mightbe multiple data warehouses where files will reside. Once there, userscan request data from the warehouse, which they do through a facilitysuch as a broker (a web-based interface that takes a request, decomposesit, identifies where in the data warehouse group of machines the dataresides, and returns the data to the user through the broker). Inembodiments the broker may give an intermediate result or may provide afinal result that is the result of the sorting, merging anddeduplicating processes. In embodiments the broker can allocate whatfiles go on what machines and then return the files when requested byusers.

More details of the calculation process are provided below. Thecalculation process may take place periodically, whether the period isdaily, weekly, monthly or on some other time schedule. In embodiments,calculations are done daily to provide clients of the host with timelyinformation. The calculation process can calculate many differentmetrics, such as the number of unique visitors to a page of content,search terms used by users, and classification of page content byindustry verticals.

FIG. 14 is a flow diagram 1400 showing steps for the processing of aparticular metric in a calculation process. First at a step 1402, thesystem takes the files that come from the pre-calculation process 500 ofFIG. 5, which are in a format such as the CL5 format 1300 of FIG. 13. Inan embodiment, the step 1402 is accomplished by a daemon that is waitingto look for files to appear in a certain defined area. The daemon isprogrammed to look for the number of files that should be producedduring that period (e.g., that day).

Next, at a step 1404, a checksum process happens for the daily (or otherperiod) CL5 files to tell whether the pre-calculation process isfinished writing the files out or not. When files are completed, theycan be appended with a suffix, e.g., Filename.done. In the files are MD5checksums of the files, so the system looks for the .done suffix andthen compares the MD5 signature to the checksum to determine whether thefiles are ready to process. If the checksum works, then the systemindicates so by a CHECKSUM OK message.

Next, at a step 1408, a job or batch handling facility manages a set ofprocessing nodes to handle processing of the files. The job/batchhandling facility is programmed to know which nodes are free (availablefor processing), which ones are busy, and which calculations can run onwhich nodes. (Some calculations can only run on certain nodes, whilesome can run on any node).

Once the handling facility hands of the processing to the nodes, thesystem checks periodically to determine whether the processing of agiven metric is completed. For example, if the metric is the number ofunique visitors to a URL, the system can at a step 1410 check to seewhether the calculation of “uniques” is completed. If calculation for ametric is not complete, then processing continues. When the metric iscomplete at the step 1410, the system initiates processing for the nextmetric at a step 1412. Of course the system may calculate differentmetrics simultaneously, rather than completing one metric and thencompleting another. The flow diagram 1400 should be understood to setout the high level steps for only one embodiment of batch processing andidentifying completion of a given metric calculation. Other embodimentswould be readily understood by one of ordinary skill in the art.

In embodiments, each day the job processing facility knows how many workorders it has in the system. It looks up the work orders for that day.When it finds files ready to run, it begins to hand them to the nodes torun. The work orders can be conditional. Thus, they can run a givenmetric if the checksum is ok for the incoming file, and they can processa given metric conditioned on completion of another metric. For a workorder, the job processing facility is programmed to know how manymachines it needs, and it reserves the machines it needs. If processinga given metric, such as “uniques” requires four nodes, then the jobprocessing facility can start running the calculation of uniques on fournodes, putting the other nodes on “wait” status. The job processingfacility does this for each metric. The job processing facility can beprogrammed with a language of its own, similar to a compiler.

At a high level, the calculation process for a given metric checks tosee if files are in the proper location, reserves machines needed forthat metric, initiates processes on the appropriate machines, andoutputs a file. Referring to FIG. 15, the file format 1500 for an outputfile from a machine contains various elements, including, in anembodiment, the date 1502, the machine 1504, the metric 1508 and asuffix or extension 1510.

Referring to FIG. 16, a schematic diagram 1600 shows a cluster ofmachines 1602 used for a calculation process. The machines can beassigned a status of “reserved”, reflected by an “R” in FIG. 16 or“available”, reflected by an A. Some machines 1602 may optionally bemade capable of accessing an external communications facility 1604, suchas the Internet, for retrieving data for use in their calculations.Other machines 1602 (or the same ones) may be made capable of accessinga data storage facility 1608, which may be an internal facility of thehost system 200 or an external data storage facility. Thus, depending onthe requirements of the calculation for the metric in question, themachines 1602 that run the calculation process can take advantage ofexternal data, as well as using the files generated in thepre-calculation process.

Once the job/batch processing facility completes calculations for agiven metric, a rollup process of the host system 200 can determine howmany files were produced for that metric that day (or period), thencombine them. For most metrics that can be accomplished by simplymerging files. For some metrics, such as unique visitors, simply mergingfiles may not be enough, because there may be a need to de-duplicate thefiles to avoid double counting a given user's visit to a URL.

Once the rollup process is complete the machine can produce a file(e.g., “date.unique”) that contains the data for that metric for thatdate. In embodiments the file can be a GZIP file.

Referring to FIG. 17, a flow diagram 1700 shows steps for calculatinganother metric, referred to herein as a “search terms” metric. In somerespects the calculation of the search terms metric is similar to thatfor other metrics, such as the “uniques” metric discussed above.However, in other respects the search terms metric requires variation ofthe steps described above. First, at a step 1702, the system initiatesthe search term metric process (which may happen upon completion ofcalculations for another metric, such as uniques, thus freeing themachines that were being used to calculate uniques). At a step 1704 thecalculation facility 210 of the host system initiates a daily job/batchprocessing run for the search terms metric. This is similar to theprocess described above for the calculation of the uniques metric,involving identification of the appropriate machines for the searchterms metric, reserving the machines, and running the calculations onthe files that came from the pre-calculation process. In the case of thesearch terms metric, not all data is found in the files that come fromthe pre-calculation process. Instead, at a step 1708 the search termcalculation process accesses external data in order to complete thecalculations for the search terms metric. Therefore, referring to FIG.16, the machines 1602 used for the search terms metrics need to have thecapability of accessing the external data facility 1608 in order tocomplete the calculations. The search terms metric calculator works notonly on CL5 files from the pre-calculation process, but also on anexternal data set (from us or a third party). The calculator takes thatinformation and uses it during the calculation.

In an embodiment, the external data is data from a dictionary of searchterms from a multiplicity of web sites. In an embodiment, the hostcollects search terms from more than 27,000 sites for use by the searchterms metric calculator. To know what the search pages and types are,the operator of the host system 200 or a third party goes to varioussites and to sections within sites and figures out what the search URLlooks like for that site. For example, for Yahoo.com the search URLmight look like: search.yahoo.com? There are a wide variety offormulations for search strings. Some take the basic form of“domain.com/p=querystring,” but others take different forms. Forexample, some sites are co-branded by two different parties. Forexample, if google.com and the Washington Post co-brand a site, the URLmay look as follows: “Wp.google.com(parameter)p=washingtonpost.com.” Thedictionary of search terms must recognize this as a Washington postsearch string, not a google.com one. Thus, the system sets up a rulethat recognizes that if the string is of the formxx.google.com/xxx?q=xxx, the credit goes to the domain identified by thequery string, not to google.com.

By way of example, Yahoo.com has hundreds of search pages on their site(finance ticker, groups, mail, etc.), so the host operator can establishor access a dictionary that takes the various forms and translates themto obtain the semantic meaning, or the host can use a rule or similarfacility to accomplish a similar function.

So, when the job runs at the node level, the search terms calculatorreads the external data, doing lookups on tables (held in node machinesin memory) to figure out who should get credit for what URL. As withrules used in pre-calculation, it is too difficult to compare each URLwith all possible search terms in the dictionary. Instead, the systemcan pass each line a single time, and the calculators figure out whetherthey should calculate something with the line or throw it out.

As with the other metrics, at a step 1710 the system rolls up the filesinto a single file ready for transfer to the data facility 120, theclient 114 or the co-location facility 118.

Referring to FIG. 18, a flow diagram 1800 sets out steps for calculatinganother metric, called “verticals.” This metric, like those describedabove, is done by a set of machines in the calculation facility 210 ofthe system 200. First, at a step 1802, the system initiates the“verticals” metric calculation. As with the other metrics, a checksumprocess ensures file integrity. Next, when machines become available,the calculation facility 200 reserves the appropriate machines forrunning the daily job/batch for the “verticals” metric calculation at astep 1804.

Next, at a step 1808, the system accesses an external communicationsfacility. Thus, the machines used for the verticals calculation must beable to access an external communications facility, which will be usedto reach an external data set. This time the system must go outside theinternal network and do something in order to allow the processing.

The term “verticals” refers to industry classifications. For example, a“vertical” might be business-to-business services, with subcategoriesranging from financial services, to office services, etc. Another set ofverticals might be business-to-consumer services, with verticalsincluding retail, financial services, etc. The system can classify anynumber of verticals.

Referring to FIG. 19, a schematic diagram 1900 shows a verticalscalculator 1902 and three main constituent components that are used forthe three main parts of the verticals calculation. The components are apage extractor module 1904, a fetcher module 1908 and a classifiermodule 1910. As can be seen in FIG. 19, the verticals calculation canuse the external communication facility 1604 for accessing an externaldata facility 1912, such as to access a lexicon or set of rules storedon the facility 1912. Therefore, it is preferably run on a machine ormachines that have that capability.

Referring to FIG. 18, once the external communications facility has beenaccessed at the step 1808, the system launches a page extractor processat a step 1810. The page extractor process reads a list of verticalsstored by in the external data facility 1912, and for each vertical itlaunches a separate process to run for each of the sites that areclassified in that vertical. For example, the B2B:Office vertical wouldrun processes for sites for Office Depot, OfficeMax, Staples, and otheroffice supplies vendors. The process is run for the high-level category(e.g., B2B), the sub-category (e.g., Office) and the sites within thesub-category. In embodiments, each site ends up getting a separateprocess launched on a separate node of the cluster of machines 214 ofthe calculator facility 210. The node knows where to look up aconfiguration file based on the hierarchy of verticals. The pageextractor process 1810 reads in title and URL key value pairs. Then theprocess reads in reads in the CL5 files for that day, and it looks fordata that matches these URLs/Title pairs to see if URLs from the CL5files match these pages. This happens for all verticals. At the end ofthe batch, the system has a subset of a CL5 file with the date, a title(e.g., office depot) and a set of URLs that match the patterns for thatsite.

Once the page extractor process 1810 is complete, the fetcher module1908 is engaged to run a fetcher process in a step 1812. The fetcherprocess reads a line in the file for a given site and determines whetherit needs to update the data for that site. If so, then the fetcherprocess 1812 downloads the identified page. If the process has seen theidentified page before, it can skip to the next one. If the fetcherprocess finds a new page, it downloads the page and puts it in thedirector of pages for that site. In embodiments the fetcher process onlyruns on certain nodes, because the host system must avoid flooding asite with downloads. The fetcher accesses an external network and inembodiments only runs on one or a few machines. The fetcher module canbe programmed to now the maximum rate at which it should pull pages. Inembodiments the fetcher module knows how to take codes for changedpages, moved pages, and indications that a site is not in operation. Ineach case it can produce alerts for the operator of the host system 200to change something.

The next step in the verticals metrics calculation engages theclassifier module 1910 is a classifying step 1814. Once the fetchermodule 1908 has downloaded any new page identifiers, then for every URLin a given file (e.g., a file for Office Depot pages), the classifiermodule 1910 writes out a record to a fetcher database. In embodimentsthis can be a flat file hierarchy held locally and mirroring the livesite, e.g.—officedepot.com/category/product/ID. Such a file can serve asan archive of the hierarchy of pages at the given site, including, forexample, product directory files for all products offered at the site.The classifier module 1910 figures out for that day how many uniqueproducts it saw. In embodiments, it goes into flat file database andknows how to open the identified page and pull out the productinformation (title, description, price, shipping status, etc.). How todo that for a given site can be stored in the configuration file for thepage extractor. It may be different for every site and page that thehost system 200 tracks. Thus, the host system operator may have to comeup with different patterns for the various pages and sites that itcovers.

The classifying step 1814 takes the information and writes out anotherfile. An example of a file structure would include elements such as theproduct name, the price, the quantity obtained for that price, the userID, and the date. For example, it might appear as follows: Redstapler/$10.00/quantity 2/ID/date. The classifier module 1910 can dothis for all of the different pages that are visited by users in the CL5files for all of the CL5 files. In embodiments the classifier module1910 can aggregate records across a category (e.g., B2B: Office). Insuch embodiments, a user of the data can compare products, such as allstaplers, to see which ones users are viewing and buying. Theclassifying step 1814 can do this for office sites, retail, financialservices, stock tickers, and other pages. In embodiments it can map aticker back to the real name for the company.

Once a classifying step 1814 is complete, then at a step 1818 the systemcan rollup the files for the verticals calculation, as it does for theother metrics that are involved in job/batch processing.

The methods and systems described above cover three out of many possiblemetrics that can be calculated. Some metrics may be run with data justfrom the CL5 files that are generated in the pre-calculation processesdisclosed above. Others require reference to an external data set aswell as data from the CL5 files. Still others require access to pageinformation, such as fetched from the Internet with the fetcher module1908. Examples of metrics include, without limitation, unique visitors,search terms, verticals, cross-correlations between sites, uses ofparticular patterns of pages, and many others. Each different metric canhave a unique calculator, typically running on a node of the cluster214, using a program coded for that metric.

The various metrics can be used by analysts to deduce information thatis relevant to many different kinds of business processes. For example,data about how users interact with pages that relate to applications fora quote on an insurance policy can produce insight into what is involvedin converting an insurance shopper into an insurance buyer.

The data obtained can be quite comprehensive. In embodiments, it mayconsist of user interactions with many thousands of pages divided intohundreds or thousands of vertical categories.

Referring to FIG. 20, a flow diagram 2000 depicts high-level steps for abusiness process using data from the methods and systems disclosedherein. At a step 2002 the system obtains clickstream data about userbehavior, such as through pre-calculation and calculation processesdescribed above. Next, at a step 2004, an analyst analyzes user behaviorbased on the nature of the clickstream data. Next, at a step 2008, theanalyst draws an inference about user behavior based on the nature ofthe clickstream data. Finally, at a step 2010, the analyst modifies abusiness process based on the inference. In embodiments, the analystmodifies an offline business process in response to inferences drawnfrom online user behavior.

The system 200 may further have a post-calculation facility 212 formerging, sorting and deduplicating the files that are generated in thecalculation process. After the post-calculation facility 212 completesthese tasks, the files can be deployed internally to data warehouses, orexternally to external data facilities, such as a co-location facility118 that can be accessed by a client.

Data that is collected and processed by the methods and systemsdisclosed herein can be used as a basis for modifying a wide range ofbusiness processes. One area is in the promotion of goods and services.It is well known that demographic information can be used as a basis fordesigning product promotion; that is, certain groups of customers aremore likely to purchase certain goods and services than others. Forexample, parents are more likely than teenagers to purchase babystrollers. Other information about user behavior can be used to assistin designing product promotion as well.

One embodiment of the method and systems disclosed herein is an improvedmethod of promoting automobiles. Automobiles are typically promoted withincentives, such as low-interest financing, rebates, and the like.Presenting the right promotion at the right time increases thelikelihood of making a sale while minimizing the cost of promotions.Understanding what vehicles a particular car model is beingcross-shopped against regionally enables the design of incentives totake account of the varying competitive set. For example, if a customershops for a Toyota Camry, is that customer more likely to look at aNissan Maxima, or a Nissan Altima, either of which could be viewed assimilar. Knowing what cross-shopping is likely to occur allows a vendorto present incentives in a manner that accounts for the likelycomparisons that the customer will make between the vendor's productsand services and potentially competitive ones. The methods and systemsdisclosed herein allow an analyst to track cross-shopping behavior andallow a vendor to modify incentives in response to inferences drawn fromcross-shopping behavior. By identifying regional variations and changesin the vehicles cross-shopped, an analyst can recommend incentives tofit the changed circumstances, thereby maximizing sales at the lowestincentive cost.

A second example would be brand positioning. One relevant factor inpresenting a marketing message is the order in which the user hasshopped various product offerings. For example, if an offering is thefirst one that a user has shopped, then it should be advertised in afashion that encourages users to purchase immediately, rather thanconsider other offers. If the user has already seen more than one offer,then the subsequent offers need to be positioned differently. If avendor is presenting an offer after many others have been considered,then the offer needs to be sufficiently arresting to get the attentionof customer late in the process. So, for purposes of branding,messaging, and marketing communications, it is valuable for a vendor toknow whether that vendor is typically the first vendor shopped, orwhether the vendor typically comes later in the process. This is truewhether the marketing message is presented online or offline.

By identifying patterns of online shopping for the products or servicesoffered by a particular vendor, the methods and systems disclosed hereinallow an analyst to determine the order in which a customer typicallyshops for products or services of that type. Then the vendor can selectand present messages, promotions, and branding that is consistent withthe position of the vendor in the typical shopping pattern. Thisapproach can be used in any product or service sector, ranging fromautomotive, to retail, financial, and others.

Knowing customer patterns can also be useful for other businesspurposes, such as demand forecasting. For example, analysis of customerinterest can determine if a predictable share of customers who havelooked at a set of competitive products and services will purchase aparticular vendor's product or service. Changes in the share of onlineusers who research goods or services can be used to predict change inmarket share offline. Thus, by allowing tracking changes in onlinemarket share, the methods and systems disclosed herein can assist inoffline business planning for changes that depend on changes in sales ormarket share, such as manufacturing and inventory needs.

Thus, data about online behavior can also help in forecasting demand.For example, in the auto market, knowing what people are researching(e.g., measuring frequency, recency and duration of online shopping forparticular models), allows the business to forecast demand forparticular make, model and trim in particular geographic regions. Thatforecast can be used allow a business to set inventory and manufacturingat optimal levels. Also online interest share changes (showing interestin a particular product) can be correlated to offline sales. Then thebusiness can manage its supply chain and manufacturing to allocate thecorrect amounts of inventory to the right places at the right time.

Another area in which tracking online user behavior can allow strategicmodification of offline business processes is in the area of retailstore operation. Retail stores are designed to encourage users to seemerchandise in a particular pattern. Stores are particularly designed topresent complementary products near each other. For example, tortillachips and salsa are usually presented in the same area of a supermarket.Also, the order in which a customer sees merchandise can make adifference in the likelihood the customer will buy a particular item.For example, studies have shown that people perceive the price of anitem to be lower if they have previously been presented with ahigher-priced item. For example, a forty-dollar tie seems less expensiveif the customer has just selected a five hundred dollar suit. Moreover,the need for the tie may be more clear to the customer if the decisionto purchase the suit has already occurred.

It is expensive and time consuming to rearrange a retail store to try tofigure out which items should be presented together, and what ordershould be used to present items. In embodiments of the methods andsystems disclosed herein, tracking user behavior online allows ananalyst to draw an inference about what items should be presentedtogether, and what items should be presented in what order, in a retailstore. For example, if it is discovered that most online users whopurchase personal computers also shop for printers, then an analystmight conclude that computers and printers should be presented together.In some cases the connection between the items might have been obvious,but in other situations a correlation between shopping for one item andshopping for another may not be readily apparent without the ability totrack and recognize statistical correlations among items, a process thatis made possible by tracking user behavior in the methods and systemsdisclosed herein. Thus, the methods and systems disclosed herein allowthe user to organize merchandise in the physical world based on onlinebehavior.

In addition to locating merchandise within a retail environment, it isalso possible to draw inferences about how to locate an entire storebased on analysis of user behavior online. For example, if goods andservices of two different vendors are identified through statisticaltechniques as complementary, then one vendor may wish to select alocation near the other vendor, even if the connection between the twois not intuitively obvious.

In other embodiments, data from online behavior can be used to drawinferences to develop offline business processes in the financialservices area. For example, businesses need to determine what productsand services should be offered through what distribution channel,whether it is an online channel, a call center, a branch, or an ATMchannel. For example, financial advice and stock quotes might best bedelivered through different channels. If online behavior shows thatcustomers examine individual stock information online, but get confusedwith mutual funds, then a business can decide to put the individualstock information online, but to offer mutual funds through otherchannels, such as advisors in branch offices. Thus, figuring out theproper offline distribution channel can be done with the assistance ofinferences drawn from online behavior.

Location decisions also benefit from online information. For example, ifa business can learn where its competitor's online shoppers come from byzip code, a business can decide to locate its physical facilities inlocations where the competitor's online shopper density is highest orlowest, as desired. This can help the business get new business fromcompetitors, rather than cannibalizing its own customer base.

Other retail business processes can also be helped. By determininginterest share by zip code, a catalog provider can, for example, dropthe customized versions of a catalog by zip code to meet regional needs.Similarly, other direct marketing campaigns, such as mail campaigns, canbe targeted to the right demographic and location based on onlineinterest.

Pricing decisions also benefit from analysis of online behavior. Forexample, knowing how the number of transactions is affected when a priceis changed can help a business determine an optimal price for goods orservices. It can be also useful to know how many people shop elsewhereafter a price increase, as compared to before. By looking at behavioracross multiple sites it is possible to set prices at the highest pointof price indifference. Thus prices can be tuned for online and offlineofferings based on online behavior data.

It is also possible to watch behavior of a competitor's customers afterthe competitor increases prices. Also, a business can introduce pricechanges online to a limited set of customers to determine sensitivitybefore making more extensive price changes offline.

The methods and systems disclosed herein can assist media businesses aswell. By determining the patterns and reasons for online migrationbetween different online content sources, it is possible to drawinferences about the customer's behavior that allow the content to bedesigned to keep the user at a given content source. For example, if areaders of Forbes regularly depart its online site to look at particularportions of Fortune's online site, it is possible to redesign thecontent of the Forbes site to contain similar content, thus diminishingthe chance the reader will depart. Thus, behavior online can be used tohelp redesign media content to retain customers. Media businesses canalso use online behavior to identify geographic areas of interest andother demographic areas of interest for books, music, news, film andother content. In turn, offline channels of distribution for mediacontent can be altered to target particular geographic or demographicgroups. Also, media businesses can target attracting customers based ontheir online behavior profile with a view to maximizing the attractionof the “best” or most loyal customers.

It is also possible to forecast demand for media content. For example,web traffic at particular sites related to upcoming movie content maytell film distributors which films should be shown on which screens andfor how long. Media providers can also determine what kind of relatedmerchandise to sell along with the media, and what kinds of promotionsto engage in. The data can be used to determine appropriate franchisingarrangements as well, such as how much to charge for a franchise todistribute toys or other novelties that reflect characters in a film.

Similar forecasting can be used before release of a new musicalcomposition, book, or other media work.

All patents, patent applications, technical specifications, books, andother documents identified herein are hereby incorporated by reference.While the invention has been described in connection with certainpreferred embodiments, other embodiments would be readily understood byone of ordinary skill in the art and are encompassed herein.

1. A method, comprising: receiving a data file containing records of aplurality of HTTP (HyperText Transfer Protocol) transactions of aplurality of users, each of the HTTP transactions including at least oneURL (Uniform Resource Locator); converting the data file into a commonfile format; cleansing the data file in the common file format byapplying a plurality of URL rules to remove session identifiers whileaccounting for the use of proxies, thereby producing a cleansed datafile containing at least one modified URL; performing a panel selectionprocess, comprising: conducting a periodic survey of a subset ofInternet users to determine characteristics of an internet communitythat includes the subset of Internet users, the characteristicsincluding demographic characteristics; selecting a panel of users fromthe subset of Internet users, the panel of users having a targetedcombination of the demographic characteristics; retaining the data fileonly when it contains a user identifier of a user in the panel of users;for each user in the panel of users, using a computer, performing atransformation process, comprising: selecting a user, removing from thedata file those URLs that do not contain the user identifier of theselected user; determining which URLs in the data file belong to asession of the selected user in the panel of users; assigning a sessionidentifier to the session; creating a plurality of session data files,each of which contain the selected user identifier, a time stamp, theURLs in the data file that belong to the session, and the sessionidentifier; decomposing, using software modules and a cluster ofmachines that run parallel calculations to decompose, the URLs in eachof the plurality of session data files so that the URLs in each of theplurality of session data files are decomposed URLs; and hashing thedecomposed URLs so that the decomposed URLs are hashed, decomposed URLs;calculating a metric of user behavior based upon the hashed, decomposedURLs; merging the metric of user behavior into a file containing aplurality of metrics of user behavior; and transmitting to a remotemachine the file containing the plurality of metrics of user behavior,wherein the file containing the plurality of metrics of user behaviorenables a third party to select an offering for automobile sales bysales region or geography.
 2. The method of claim 1, wherein the salesregion is identified by a zip code.
 3. The method of claim 1, whereinthe offering relates to an incentive.
 4. The method of claim 1, whereinoffering relates to financing.
 5. The method of claim 1, whereinoffering relates to automobile feature.
 6. The method of claim 1,wherein the file containing the plurality of metrics of user behaviorfurther enables the third party to select a timing of the offering. 7.The method of claim 1, wherein at least one of the URL rules isgenerated by the computer.
 8. The method of claim 1, wherein theparallel calculations include the calculating of the metric of userbehavior based upon the hashed, decomposed URLs.
 9. The method of claim1, wherein converting the data file into a common file format includes:identifying a data provider for the data file; and applying a set ofrules specific to the data provider to the data file.
 10. A hostcomputer, comprising: a data collection facility that receives a datafile containing records of a plurality of HTTP(HyperText TransferProtocol) transactions of a plurality of users, each of the HTTPtransactions including at least one URL (Uniform Resource Locator);checks for integrity of the data file and the records; and converts thedata file into a common file format; a pre-calculation facilityincluding one or more computers, the pre-calculation facility beingconfigured to perform a cleansing process, a panel selection process,and a transformation process, wherein the cleansing process comprises:cleansing the data file in the common file format by applying aplurality of URL rules to remove session identifiers while accountingfor the use of proxies, thereby producing a cleansed data filecontaining at least one modified URL; the panel selection processcomprises: conducting a periodic survey of a subset of Internet users todetermine characteristics of an internet community that includes thesubset of Internet users, the characteristics including demographiccharacteristics; selecting a panel of users from the subset of Internetusers, the panel of users having a targeted combination of thedemographic characteristics; retaining the data file only when itcontains a user identifier of a user in the panel of users; thetransformation process comprises, for each user in the panel of users:selecting a user, removing from the data file those URLs that do notcontain the user identifier of the selected user; determining which URLsin the data file belong to a session of the selected user in the panelof users; assigning a session identifier to the session; creating aplurality of session data files, each of which contain the selected useridentifier, a time stamp, the URLs in the data file that belong to thesession, and the session identifier; decomposing, using software modulesand a cluster of machines that run parallel calculations to decompose,the URLs in each of the plurality of session data files so that the URLsin each of the plurality of session data files are decomposed URLs; andhashing the decomposed URLs so that the decomposed URLs are hashed,decomposed URLs; and a calculation facility that calculates a metric ofuser behavior based upon the hashed, decomposed URLs, performs apost-calculation process, and transmits to a remote machine a filecontaining a plurality of metrics of user behavior, wherein the filecontaining the plurality of metrics of user behavior enables the thirdparty to select an offering for automobile sales by sales region orgeography, and wherein the post-calculation process comprises: mergingthe metric of user behavior into a file containing a plurality ofmetrics of user behavior.
 11. The host computer of claim 10, wherein thesales region is identified by a zip code.
 12. The host computer of claim10, wherein the offering relates to an incentive.
 13. The host computerof claim 10, wherein the offering relates to financing.
 14. The hostcomputer of claim 10, wherein the offering relates to an automobilefeature.
 15. The host computer of claim 10, wherein the file containinga plurality of metric of user behavior further enables the third partyto select a timing of the offering.
 16. The host computer of claim 10,wherein at least one of the URL rules is generated by the host computersystem.
 17. The host computer of claim 10, wherein the parallelcalculations include the calculating of the metric of user behaviorbased upon the hashed, decomposed URLs.
 18. The host computer of claim10, wherein the data collection facility converts the data file into acommon file format by: identifying a data provider for the data file;and applying a set of rules specific to the data provider to the datafile.